1. Field of the Invention
The present invention relates, generally, to read-only memory (ROM) within a system on a chip (SoC) and, in preferred embodiments, to method and system for overriding selected ROM code functions or adding new code functions within an SoC.
2. Description of Related Art
An SoC is used in many computer and communication applications. An SoC generally comprises a microprocessor embedded on a chip. The microprocessor is coupled to a local bus on the chip. Included on this single chip are the hardware components required for a specific application. SoCs are usually more application-specific than general integrated circuits.
FIG. 1 illustrates exemplary SoC 101. SoC 101 comprises processor 100, which is electrically coupled to instruction cache 102 and data cache 104. Instruction cache 102 and data cache 104 are electrically coupled to processor local bus 106. SoC 101 also comprises various other hardware components that would be specific to a particular application. Examples of such typical hardware components are LCD display controller 112, keyboard controller 114, universal serial bus (USB) 116 and personal computer (PC) card interface 118. These components are electrically coupled to processor local bus 106. These hardware components are also connectable to devices that are external to SoC 101. In this example, LCD display controller 112 is electrically coupled to display screen 120, keyboard controller 114 is electrically coupled to keyboard 122, USB 116 is electrically coupled to peripheral 124, and PC card interface 118 is electrically coupled to PC card 126.
Memory interface 110 is provided on exemplary SoC 101 to act as an interface between external flash memory 190 and Static Random Access Memory (SRAM) 192 and processor local bus 206. Data and instructions executable by processor 100 can be stored in flash memory 190 and SRAM 192.
In certain applications where proprietary information needs to be safeguarded or in cryptographic and other applications where information security is important, it is often advantageous to also include ROM on-board the SoC. Because ROM resides on the SoC and is programmed in manufacturing, unauthorized access to the code within the ROM is made more difficult. This allows greater security against reverse engineering of proprietary code and against cryptographic attacks on secure information.
It will be assumed that exemplary SoC 101 is dedicated to such an application and therefore SoC 101 further comprises ROM 108, which is electrically coupled to processor local bus 106. Along with the advantages in the use of ROM on SoCs there are major drawbacks. One such drawback is that the ROM fabricated on the SoC cannot be changed. However, frequently errors or “bugs” in the ROM code are discovered after the ROM has been fabricated on the SoC. These bugs must be addressed and repaired in order to ensure the integrity of the code and of the overall functioning of the SoC.
One method for repairing bugs is to make the necessary corrections in the ROM code, program a new ROM, and then re-fabricate the SoC. This method results in either scrapping the SoCs with the old ROMs that contain bugs or selling these SoCs at a reduced price for use in limited applications (i.e., those in which the known bugs have an insignificant impact on the application). This method of repairing bugs can be very expensive and time consuming. In addition, subsequent testing of the re-fabricated SoC may reveal additional bugs requiring another re-fabrication and additional expenses and delays.
FIG. 2 illustrates a second method used in repairing bugs in ROM code. SoC 201 comprises processor 200, instruction cache 202, data cache 204, processor local bus 206, memory interface 210, and ROM 208. In addition FIG. 2 shows external flash memory 290, which is connected to processor local bus 206 through memory interface 210.
If bugs exist in the ROM code, they will be within particular code functions. Code functions may contain instructions, data, or both instructions and data. Longer and/or more complex code functions will have a higher likelihood of containing bugs than shorter and/or less complex code functions. Therefore, when ROM 208 is programmed, system designers usually place test code at the beginning of code functions that are more likely to have bugs. Blocks 230, 232, 234, 236, 238, 240, 242, 244, 246, and 248 in FIG. 2 represent code functions 1, 2, 3, 4, 5, 6 ,7, 8, 9 and 10 respectively. FIG. 2 also shows two examples of test code, test 250 and test 252, located at the beginning of particular code functions. The operation of the test code is discussed in further detail below.
In FIG. 2 it is assumed that code functions 3 and 8 within ROM 208 are likely to have bugs. Therefore two tests, test 250 and test 252, are placed at the beginning of code functions 3 and 8 respectively. Each test is associated with a test bit located in a memory outside of ROM 208, which is flash memory 290 in the present example. This test bit will previously have been programmed to be in a “true” state if it has earlier been determined through testing of ROM 208 that its associated code function does indeed contain a bug.
When, during run-time, the test code within the tested code function is executed by processor 200, it will sample its associated test bit in flash memory 290. If processor 200 detects a true state on the test bit, processor 200 will not fetch the erroneous code function that is in ROM 208, but instead will fetch a replacement code function, also referred to in the present application as a “patch,” that has previously been programmed into flash memory 290. Referring to FIG. 2., blocks 254, 256, 258 and 260 within flash memory 290 represent patches 1, 2, 3 and 4, respectively. Thus, the above described method “repairs” bugs in the ROM by overriding them with patches during run-time.
However, this method of overriding bugs has two problems associated with it. First, the extra lines of test code placed at the beginning of those code functions with a likelihood of containing bugs diminishes the performance of the SoC. The processor must spend time executing this test code at the beginning of each tested code function. Second, the performance of the SoC is further diminished by the run-time fetching of patches from flash memory 290 to replace ROM code functions containing bugs. This diminished performance is due to increased access time resulting from the lower frequencies achievable outside of the SoC.
Thus, a system designer normally does not place the test code at the beginning of every code function within the ROM. While this would be the surest way of repairing all bugs and ensuring reliability, the increase in code lines and subsequent diminished performance of the SoC would be unacceptable. Hence, the system designer must balance performance against reliability. Even if very few code functions are tested there will be some diminished performance of the SoC.
Another problem with this method results from the fact that because not every code function is tested, the possibility exists that bugs will remain in untested code functions. These untested code functions can not be repaired by the method described above, because there is no test bit associated with untested code functions. This fact can lead to a perpetuation of the bug throughout the ROM code through code branching, as described below.
Code branching results when one code function calls another code function within the code. The called code function is then executed by the processor. After execution of the called code function, the processor returns to the calling code function and continues execution of that code function. Code branching can occur in either direction. For example, code function 10 can branch backwards to code function 1.
Referring again to FIG. 2, directed lines 270, 272 and 274 represent code branching between different code functions within the code. Directed line 270 represents a code branch from code function 1 to code function 3. Similarly, directed line 272 represents a code branch from code function 3 to code function 6. Finally, directed line 274 represents a code branch from code function 6 to code function 10.
Thus, it can be seen from the above discussion that if an untested code function contains a bug and if the results of the execution of that code function by the processor are shared with other code functions through code branching, then the number of unreliable code functions increases. Even tested code functions that have previously been “repaired” may nevertheless become unreliable again after branching to another code function.
Finally, in addition to the difficulties involved in repairing bugs in the ROM code discussed above, it is also impossible to add additional code functions to the ROM code. Such additional ROM code functions may be determined by the system designer to be desirable after the ROM has already been programmed and fabricated within the SoC.